Genotype and Phenotype of Software Products [6/100]

I’m writing 100 posts about product development and product management. For this challenge I take weekly cadence, so you can expect a new post every week (or less). This is post #6.

I love analogies. They don’t always work, but they help to generate completely new ideas. I encountered genotypes and phenotypes concepts while reading Stanislaw Lem, and immediately tried to apply them to software products.

Genotype vs. Phenotype

Genotype is a set of system properties. For example, eye color or height are defined by your genes. Phenotype is a sum of a system’s observable characteristics and it is formed by system properties and external environment. For example, you and your friend Teddy have some genes that can make both of you allergic. However, your mom was too caring and taught you to wash your hands with an anti-bacterial soup 10 times per day, while Teddy’s mom allowed Teddy to play in the mud and eat some dirt. As a result, you became allergic due to gene expression and hate April, while Teddy is doing fine and enjoys poplar trees.

Genotype and Phenotype in software products

Let’s take some software product and examine it. How about Jira? Let’s take Jira. Jira has a set of features (genotype), but every customer configures Jira for their own needs, so every Jira instance is a phenotype. From an evolutionary point of view, Jira genotype spawns many instances that interact with the external environment (customers context). These instances may survive (a company is happy with the product) or die (a company is not happy and churns).

External context significantly affects Jira instance. Jira phenotype accumulates information about company domain and work processes, usage patterns, settings, integrations, extensions, etc. This information may cause mutations (changes) in the Jira genotype (new features, improved features). In a nutshell, this is what the Product Manager does — accumulates information about product phenotypes and plans changes in product genotype to increase product survivability and expansion (something close to selective breeding) 🍌.

We see that product evolution is greatly affected by an external environment. There are two major kinds of environments.

Uniform environment

When all customers use a product quite similarly, the product manager receives a volume of similar improvement signals from customers. It makes her work much easier since required changes and improvements are easy to define. With time product will evolve to a good set of genes (features) that fits many new potential customers. For example, accounting processes are well defined, so it’s relatively easy to create a good accounting product based on 10 customers’ feedback, you don’t need huge diversity or large users base in narrow domains to create a good product.

In an extreme case when you have a single large customer genotype = phenotype. Indeed you implement all requirements for this specific customer and feel good.

Diverse environment

Product manager life becomes much harder in a diverse environment. Each product instance is a unique phenotype. As a result, customers ask for different features and it’s impossible to make conclusions from 10 customers’ feedback. Or even from 100 customers. You have so much diversity that it’s hard to have a good prioritization techniques for features. For example, you may add a feature that will make happy 10% of your customers, but 90% will never use it. In general, many requested features are needed for specific niches and it’s very hard to find features that 80% of the customers need.

Take Airtable, Notion, or Fibery. People use these tools for hundreds of cases in a very different contexts. Feedback diversity is huge! What to do?

The solution is a flexible (variable) product genotype. A product should be able to express certain genes and survive in the new context 🧬. In other words, a customer should be able to “activate” certain features in a product and build the required phenotype. There are several ways to solve this problem, let’s briefly examine them:

1. Extensive features set. Here a product has many many specific features and you use only needed features. Some configurations to enable/disable features may exist. For example, you have a built-in Time Tracking feature, but if you don’t need it, you just hide it. This is relatively easy to implement, but the composability of separate features is low, maintenance is hard and a product quickly becomes complicated. ClickUp is a good example.

2. Platform + Plug-ins. Here you provide a platform to build specific extensions that solve specific problems. This is a better way to go, since the base platform may be relatively simple. In this case, Time Tracking is a plugin. However, extensions are created by other companies and it is hard to keep a product coherency here (extensions UI might be different, etc). Jira fits this category.

3. 🦋 No-code tool. Here you provide a set of building blocks and teach users to build their solutions on top. In this case, Time Tracking should be composed of existing building blocks. This is the best solution in theory, but it is the hardest to implement. The learning curve will be high. Airtable and Fibery are in this category.

Interestingly, flexible products with flexible genotypes have a positive feedback loop that pushes products into more flexibility.

Flexible product → New unexpected use case → new requests to have even more flexibility → More flexible product.

We have this feedback loop with Fibery. More flexibility usually means more complexity, so you have to think about getting started deep and every new building block should be justified. Flexibility is hard!